Remarks 

I. Claim Rejections - 35 U.S.C. §102 

The Office Action rejects claims 1-4, 6, 7 and 14 under 35 U.S.C. § 102(e) as 

being anticipated by U.S. Patent No. 5,828,835 to Isfeld et al. (hereinafter "Meld"). 

Regarding claim 1, the Office Action states: 

As per claim 1, Isfeld teaches a method of outputting a first 
TCP/IP packet and a second TCP/IP packet from a network interface 
device, the first TCP/IP packet and the second TCP/IP packet being output 
to a network (e.g. Isfeld, Abstract, col. 1, lines 20-27), comprising: 

(a) storing first packet information on the network interface device 
(e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 

(b) pushing a first pointer to the first packet information onto a first 
transmit queue of the network interface device (e.g. Isfeld, col. 2, lines 59- 
63; col. 3, lines 16-29); 

(c) storing second packet information on the network interface 
device (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 

(d) pushing a second pointer to the second packet information onto 
a second transmit queue of the network interface device (e.g. Isfeld, col. 2, 
lines 59-63; col. 3, lines 16-29); and 

(e) popping the second pointer off the second transmit queue and 
then popping the first pointer off the first transmit queue, the popped 
second pointer being used to locate the second packet information, the 
located second packet information then being output from the network 
interface device in the form of a second TCP/IP packet, the popped first 
pointer being used to locate the first packet information, the located first 
packet information being output from the network interface device in the 
form of a first TCP/IP packet such that the second TCP/IP packet is output 
from the network interface device and to the network before the first 
TCP/IP packet is output from the network interface device and to the 
network (e.g. Isfeld, col. 2, lines 54-67; col. 3, lines 1-15). 

Applicants respectfully disagree with the Office Action assertion that "Isfeld 
teaches a method of outputting a first TCP/IP packet and a second TCP/IP packet from a 
network interface device, the first TCP/IP packet and the second TCP/IP packet being 
output to a network (e.g. Isfeld, Abstract, col. 1, lines 20-27)." Instead, Isfeld states in 
the first lines of its SUMMARY that its invention "provides a connectionless 
communication protocol," teaching away from TCP. Isfeld emphasizes the importance of 
its connectionless protocol throughout that disclosure. See, e.g., Abstract, lines 1-2; 
column 2, lines 4-37; column 3, lines 1-4; column 4, lines 28-34, 43-47, 52-54; 
independent claims 1, 23, 34 and 56. 
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Similarly, applicants respectfully disagree with the Office Action assertion that 
"Isfeld teaches. . . the located second packet information then being output from the 
network interface device in the form of a second TCP/IP packet, the popped first pointer 
being used to locate the first packet information, the located first packet information 
being output from the network interface device in the form of a first TCP/IP packet such 
that the second TCP/IP packet is output from the network interface device and to the 
network before the first TCP/IP packet is output from the network interface device and to 
the network (e.g. Isfeld, col. 2, lines 54-67; col. 3, lines 1-15)." As mentioned above, 
Isfeld teaches away from TCP, which is well known to be a connection-oriented protocol. 

For at least these reasons, applicants respectfully assert that Isfeld does not 
anticipate claim 1 or any claim that depends from claim 1. 

Regarding claim 2, the Office Action states: 

As per claim 2, Isfeld teaches the method of Claim 1, wherein the 
first TCP/IP packet is a data packet, wherein the second TCP/IP packet is 
a control packet (e.g. Isfeld, col. 1, lines 60-67; col. 2, lines 1-3), and 
wherein the network interface device is coupled to a host computer by a 
parallel bus (e.g. Isfeld, col. 6, lines 13-17). 

Applicants respectfully assert that neither column 1, lines 60-67 nor column 2, 
lines 1-3 of Isfeld teach "wherein the first TCP/IP packet is a data packet, wherein the 
second TCP/IP packet is a control packet," in contrast to claim 2 and the Office Action 
assertions. 

Regarding claim 3, the Office Action states: 

As per claim 3, Isfeld teaches the method of Claim 1, wherein the 
first transmit queue contains pointers associated with a first set of packets, 
and wherein the second transmit queue contains pointers associated with a 
second set of packets, the second set of packets having transmission 
priority over the first set of packets (e.g. Isfeld, col. 2, lines 54-67; col. 3, 
lines 1-15). 

Applicants respectfully assert that neither column 2, lines 54-67 nor column 3, 
lines 1-15 of Isfeld teach "wherein the first transmit queue contains pointers associated 
with a first set of packets, and wherein the second transmit queue contains pointers 
associated with a second set of packets," in contrast to claim 3 and the Office Action 
assertions. 
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Regarding claim 4, the Office Action states: 

As per claim 4, Isfeld teaches the method of Claim 1, wherein the 
network interface device comprises a transmit sequencer, a memory, and 
MAC interface circuitry, the transmit sequencer causing the second packet 
information to be transferred from the memory to the MAC interface 
circuitry, the second TCP/IP packet being output from the network 
interface device through the MAC interface circuitry (e.g. Isfeld, col. 6, 
lines 36-44; col. 7, lines 1-15). 

Applicants respectfully assert that neither column 6, lines 36-44 nor column 7, 
lines 1-15 of Isfeld teach "wherein the network interface device comprises a transmit 
sequencer, a memory, and MAC interface circuitry, the transmit sequencer causing the 
second packet information to be transferred from the memory to the MAC interface 
circuitry," in contrast to claim 4 and the Office Action assertions. Moreover, Applicants 
respectfully assert that neither column 6, lines 36-44 nor column 7, lines 1-15 of Isfeld 
teach "the second TCP/IP packet being output from the network interface device through 
the MAC interface circuitry," in contrast to claim 4 and the Office Action assertions. 

Regarding claim 14, the Office Action states: 

As per claim 14, Isfeld teaches a TCP/IP offload network interface 
device (e.g. Isfeld, Abstract, col. 1, lines 20-27), comprising: 

a memory containing first packet information and second packet 
information (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 

a processor that causes a first pointer to the first packet information 
to be pushed onto a first transmit queue before a second pointer to the 
second packet information is pushed onto a second transmit queue (e.g. 
Isfeld, col. 2, lines 54-67; col. 3, lines 1-15); and 

a transmit mechanism that pops the second queue in preference to 
popping the first queue, the transmit mechanism popping the second 
pointer off the second queue and outputting the second packet information 
from the network interface device in the form of a second TCP/IP packet, 
the transmit mechanism popping the first pointer off the first queue and 
outputting the first packet information from the network interface device 
in the form of a first TCP/IP packet, the transmit mechanism popping the 
second pointer from the second queue before popping the first pointer off 
the first queue, the second TCP/IP packet being output from the network 
interface device before the first TCP/IP packet is output from the network 
interface device (e.g. Isfeld, col. 2, lines 54-67; col. 3, lines 1-15). 

Applicants respectfully disagree with the Office Action assertion that "Isfeld 
teaches a TCP/IP offload network interface device (e.g. Isfeld, Abstract, col. 1, lines 20- 
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27)." As noted above, Isfeld teaches away from TCP. In addition, Isfeld does not teach 
or suggest offloading TCP or IP. 

Moreover, applicants respectfully disagree with the Office Action assertion that 
"Isfeld teaches ... the transmit mechanism popping the second pointer off the second 
queue and outputting the second packet information from the network interface device in 
the form of a second TCP/IP packet, the transmit mechanism popping the first pointer off 
the first queue and outputting the first packet information from the network interface 
device in the form of a first TCP/IP packet, the transmit mechanism popping the second 
pointer from the second queue before popping the first pointer off the first queue, the 
second TCP/IP packet being output from the network interface device before the first 
TCP/IP packet is output from the network interface device (e.g. Isfeld, col. 2, lines 54-67; 
col. 3, lines 1-15)." There is simply no teaching in Isfeld of these limitations. 

For at least these reasons, applicants respectfully assert that Isfeld does not 
anticipate claim 14 or any claim that depends from claim 14. 

Regarding claim 15, the Office Action states: 

As per claim 15, Isfeld teaches the TCP/IP offload network 
interface device of Claim 14, wherein the first TCP/IP packet is a data 
packet, and wherein the second TCP/IP packet is a control packet (e.g. 
Isfeld, col. 1, lines 60-67; col. 2, lines 1-3). 

Applicants respectfully assert that neither column 1, lines 60-67 nor column 2, 
lines 1-3 of Isfeld teach "wherein the first TCP/IP packet is a data packet, and wherein 
the second TCP/IP packet is a control packet," in contrast to claim 4 and the Office 
Action assertions. 

II. Claim Rejections - 35 U.S.C. §103 

1. The Office Action rejects claims 5, 9, 1 1 and 16-18 under 35 U.S.C. 

§ 103(a) as being unpatentable over Isfeld in view of U.S. Patent No. 6,078,564 to 

Lakshman et al. (hereinafter "Lakshman"). Regarding claim 5, the Office Action states: 

As per claim 5, Isfeld teaches the method of claim 1, wherein the 
pushing of (b) occurs before the pushing of (d) (e.g. Isfeld, col. 2, lines 54- 
67; col. 3, lines 1-15). 
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Isfeld fails to teach the method wherein the first TCP/IP packet is 
associated with a first TCP/IP connection, and wherein the second TCP/IP 
packet is associated with a second TCP/IP connection. 

However, in a similar art, Lakshman teaches a network 
communications system that uses multiple transmit queues, one for control 
(ACK) packets and one for data packet pointers, using a separate 
connection per transmit queue (e.g. Lakshman, col. 3, lines 26-33). 

It would have been obvious to one skilled in the art at the time the 
invention was made to combine Lakshman with Isfeld because of the 
advantages of allowing separate packets to be associated with separate 
network connections. Allowing packets to be transmitted and received 
over various connections at various times is a standard feature for any 
communication network. The use of multiple network connections helps 
to eliminate network congestion that would occur when using only a 
single connection. Network congestion can greatly slow the efficiency of 
packet transmission, often times leading to dropped or lost packets. 
Reducing or eliminating network congestion is a benefit in any 
communications network system. 

Applicants respectfully disagree with the Office Action statement that: "It would 
have been obvious to one skilled in the art at the time the invention was made to combine 
Lakshman with Isfeld because of the advantages of allowing separate packets to be 
associated with separate network connections." As mentioned above, Isfeld teaches away 
from using network connections, for example by stating in the first lines of its 
SUMMARY that its invention "provides a connectionless communication protocol." 
Isfeld emphasizes the importance of its connectionless protocol throughout that 
disclosure. See, e.g., Abstract, lines 1-2; column 2, lines 4-37; column 3, lines 1-4; 
column 4, lines 28-34, 43-47, 52-54; independent claims 1, 23, 34, 56. Teaching away 
is strong evidence of nonobviousness. 

Applicants respectfully submit that the general attributes of using connection- 
oriented verses connectionless protocols were likely known to those of skill in the art 
such as Isfeld, who nonetheless repeatedly teaches that his invention is to be used with 
connectionless rather than connection-oriented protocols. 

Applicants also respectfully disagree with the Office Action assertion that: "The 
use of multiple network connections helps to eliminate network congestion that would 
occur when using only a single connection." Because this assertion appears to come 
from the Examiner's personal knowledge rather than anything in the cited references, 
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applicants respectfully request the Examiner to provide a supporting affidavit as required 
by 37 C.F.R. § 1.1 04(d)(2). 

For at least these reasons, applicants respectfully assert that claim 5 is nonobvious 
over the combination of Isfeld and Lakshman proposed by the Office Action. 

Regarding claim 9, the Office Action states: 

As per claim 9, Isfeld teaches the method of claim 1, wherein the 
second TCP/IP packet is a control packet (e.g. Isfeld, col. 1, lines 60-67; 
col. 2, lines 1-3), but fails to teach the method wherein the second TCP/IP 
packet is a TCP ACK. 

However, in a similar art, Lakshman teaches a network 
communications system that uses multiple transmit queues, one for control 
(ACK) packets and one for data packet pointers, and the various uses of 
the ACK control packet (e.g. Lakshman, col. 4, lines 38-44, 53-59). 

It would have been obvious to one skilled in the art at the time the 
invention was made to combine Lakshman with Isfeld because of the 
benefits of using an acknowledgement (ACK) response in a 
communications network. The use of ACK responses further assists a 
communications network in reducing network congestion and informs the 
transmitter when a packet has been dropped. This increases the speed, 
efficiency and reliability of a network, all of which are beneficial in any 
communications network system. 

Applicants respectfully disagree with the Office Action assertion that "Isfeld 
teaches the method of claim 1, wherein the second TCP/IP packet is a control packet (e.g. 
Isfeld, col. 1, lines 60-67; col. 2, lines 1-3)." Applicants respectfully assert that Isfeld 
teaches away from TCP, as mentioned above. 

Applicants also respectfully disagree with the Office Action statement that: "It 
would have been obvious to one skilled in the art at the time the invention was made to 
combine Lakshman with Isfeld because of the benefits of using an acknowledgement 
(ACK) response in a communications network." As mentioned above, Isfeld teaches 
away from using network connections, for example by stating in the first lines of its 
SUMMARY that its invention "provides a connectionless communication protocol." 
Isfeld emphasizes the importance of its connectionless protocol throughout that 
disclosure. See, e.g., Abstract, lines 1-2; column 2, lines 4-37; column 3, lines 1-4; 
column 4, lines 28-34, 43-47, 52-54; independent claims 1, 23, 34, 56. Teaching away 
is strong evidence of nonobviousness. 
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In fact, even the very section of Isfeld cited by the Office Action states, in column 
1, line 67 - column 2, line 3: "Thus, it is desirable to limit the amount of control 
messages transmitted on the communication link among the distributed processing nodes 
in order to enhance data throughput," teaching away from the use of ACKs, which the 
Office Action asserts are control packets. 

Applicants also respectfully disagree with the Office Action assertion that: "The 
use of ACK responses further assists a communications network in reducing network 
congestion," especially because this statement contradicts the teaching of Isfeld quoted 
immediately above. Because this assertion appears to come from the Examiner's 
personal knowledge rather than anything in the cited references, applicants respectfully 
request the Examiner to provide a supporting affidavit as required by 37 C.F.R. 
§1. 104(d)(2). 

For at least these reasons, applicants respectfully assert that claim 9 is nonobvious 
over the combination of Isfeld and Lakshman proposed by the Office Action. 
Regarding claim 1 1, the Office Action states: 

As per claim 11, Isfeld teaches the method of claim 1, wherein the 
first transmit queue is used for the transmission of TCP/IP data 
packets(e.g. Isfeld, col. 1, lines 60-67; col. 2, lines 1-3). 

Isfeld fails to teach the method wherein the second transmit queue 
is used for the transmission of TCP ACKs, the second transmit queue 
being free of or substantially free of pointers to TCP/IP data packets. 

However, in a similar art, Lakshman teaches a network 
communications system that uses multiple transmit queues, one for control 
(ACK) packets and one for data packet pointers, each pointer type being 
placed into its own queue, leaving the other queues free of unnecessary 
types of information (e.g. Lakshman, col. 4, lines 38-44, 53-59). 

It would have been obvious to one skilled in the art at the time the 
invention was made to combine Lakshman with Isfeld for similar reasons 
as stated above in regards to claim 9. 

Applicants respectfully disagree with the Office Action assertion that "Isfeld 
teaches the method of claim 1, wherein the first transmit queue is used for the 
transmission of TCP/IP data packets(e.g. Isfeld, col. 1, lines 60-67; col. 2, lines 1-3)." 
Applicants respectfully assert that Isfeld teaches away from TCP, as mentioned above. 

Applicants also respectfully disagree with the Office Action statement that: "It 
would have been obvious to one skilled in the art at the time the invention was made to 
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combine Lakshman with Isfeld for similar reasons as stated above in regards to claim 5." 
As mentioned above, Isfeld teaches away from using network connections, and even the 
very section of Isfeld cited by the Office Action teaches away from the use of TCP, 
which includes a number of control packets. 

For at least these reasons, applicants respectfully assert that claim 1 1 is 
nonobvious over the combination of Isfeld and Lakshman proposed by the Office Action. 

Regarding claim 16, the Office Action states: 

As per claim 16, Isfeld teaches the TCP/IP offload network 
interface device of Claim 14, but fails to teach wherein the first TCP/IP 
packet is a data packet associated with a first TCP/IP connection and 
wherein the second TCP/IP packet is a TCP ACK associated with a second 
TCP/IP connection. 

However, in a similar art, Lakshman teaches a network 
communications system that uses multiple transmit queues, one for control 
(ACK) packets and one for data packet pointers, each pointer type being 
placed into its own queue, leaving the other queues free of unnecessary 
types of information (e.g. Lakshman, col. 4, lines 38-44, 53-59). 

It would have been obvious to one skilled in the art at the time the 
invention was made to combine Lakshman with Isfeld for similar reasons 
as stated above in regards to claim 9. 

Applicants respectfully disagree with the Office Action assertion that "Isfeld 
teaches the TCP/IP offload network interface device of Claim 14." Applicants 
respectfully assert that Isfeld teaches away from TCP, as mentioned above. 

Applicants also respectfully disagree with the Office Action statement that: "It 
would have been obvious to one skilled in the art at the time the invention was made to 
combine Lakshman with Isfeld for similar reasons as stated above in regards to claim 9." 
As mentioned above, Isfeld teaches away from using TCP, network connections and 
ACKs. 

For at least these reasons, applicants respectfully assert that claim 16 is 

nonobvious over the combination of Isfeld and Lakshman proposed by the Office Action. 

Regarding claim 18, the Office Action states: 

As per claim 18, Isfeld and Lakshman teach the TCP/IP offload 
network interface device of Claim 16, wherein the network interface 
device includes a second processor, the second processor executing a 
protocol processing stack, the second processor being part of the TCP/IP 
offload network interface device (e.g. Isfeld, col. 8, lines 16-34). 
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Applicants respectfully disagree with the Office Action assertion that "Isfeld and 
Lakshman teach the TCP/IP offload network interface device of Claim 16." Applicants 
respectfully assert that Isfeld teaches away from TCP, as mentioned above. 

Applicants also respectfully disagree with the Office Action statement that "Isfeld 
and Lakshman teach the . . . the second processor being part of the TCP/IP offload 
network interface device (e.g. Isfeld, col. 8, lines 16-34)." Applicants respectfully assert 
the cited passage does not teach "the second processor being part of the TCP/IP offload 
network interface device." 

For at least these reasons, applicants respectfully assert that claim 18 is 
nonobvious over the combination of Isfeld and Lakshman proposed by the Office Action. 



2. The Office Action rejects claims 8, 12 and 13 under 35 U.S.C. §103(a) as 
being unpatentable over Isfeld in view of U.S. Patent No. 5,682,534 to Kapoor et al. 
(hereinafter "Kapoor"). Regarding claim 8, the Office Action states: 

As per claim 8, Isfeld teaches the method of claim 1, but fails to 
teach the method further comprising: 

receiving onto the network interface device from the network a 
third packet; 

fast-path processing the third packet on the network interface 
device such that a data payload portion of the third packet is written into a 
destination memory without a network protocol stack performing 
substantial transport or substantial network layer protocol processing on 
the third packet; 

receiving onto the network interface device from the network a 
fourth packet; and 

slow-path processing the fourth packet such that at least a data 
payload portion of the fourth packet is written into the destination 
memory, the network protocol stack performing substantial transport and 
substantial network layer protocol processing on the fourth packet. 

However, in a similar art, Kapoor teaches a network 
communication system that receives packets onto a network interface 
device and is able to perform both "fast-path" and "slow-path" processing 
on the packet, depending on certain characteristics determined at the time 
the packet is received; the "fast-path" processing avoids protocol 
processing in both the network and transport layers, accelerating the 
packet through the device (e.g. Kapoor, col. 2, lines 33-49; col. 6, lines 7- 
19; Fig. 2B) and the "slow-path" processing processes the packet through 
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all applicable layers of the protocol stack if it does not meet the defined 
requirements for "fast-path" processing (e.g. Kapoor, col. 5, lines 36-45). 

It would have been obvious to one skilled in the art at the time the 
invention was made to combine Kapoor with Isfeld because of the 
advantages of allowing certain packets which do not need full protocol 
stack processing to avoid the unnecessary processing to avoid the 
unnecessary processing and be given a "fast-path" through the device. As 
Kapoor states, bypassing the unnecessary processing layers provides for 
significant performance gains (e.g. Kapoor, col. 2, lines 48-49). When the 
network device skips processing on each layer of the protocol stack, the 
packet passes through the device much faster and more efficiently. Only 
packets that need to be processed in each layer are pass through the "slow- 
path" which can greatly increase the speed and efficiency of network 
communication. This is beneficial in any communications network 
system. 

Applicants agree with the Office Action admission that Isfeld fails to teach any of 
the limitations of claim 8. 

Applicants respectfully disagree, however, with the Office Action statement that 
"Kapoor teaches a network communication system that receives packets onto a network 
interface device and is able to perform both 'fast-path' and 'slow-path' processing on the 
packet, depending on certain characteristics determined at the time the packet is received; 
the 'fast-path' processing avoids protocol processing in both the network and transport 
layers, accelerating the packet through the device (e.g. Kapoor, col. 2, lines 33-49; col. 6, 
lines 7-19; Fig. 2B) and the 'slow-path' processing processes the packet through all 
applicable layers of the protocol stack if it does not meet the defined requirements for 
'fast-path' processing (e.g. Kapoor, col. 5, lines 36-45)." 

Applicants note that instead of receiving packets onto a network interface device 
from a network and then avoiding protocol processing on the received packets, Kapoor is 
directed to "managing remote procedure calls (RPCs) between client and server 
processes running on the same host computer in a network." Kapoor, column 2, lines 
34-36, emphasis added. Similarly, Kapoor teaches: "It is another object of the invention 
to enable a network RPC mechanism to distinguish whether client and server processes 
are running on the same host machine and, if so, to bypass the network and transport 
layers using an alternate protocol sequence that exploits local interprocess 
communication (IPC) facilities." Kapoor, column 2, lines 37-43, emphasis added. 
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Likewise, Kapoor teaches: "It is a more specific object of the invention to recognize 
when client and server DCE processes exist on the same host to thereby use a local IPC 
mechanism, instead of a network layer (IP) or transport layer (TP) path, to implement a 
remote procedure call." Kapoor, column 2, lines 44-48, emphasis added. 

In contrast to these teachings of Kapoor, claim 8 recites in part "receiving onto 
the network interface device from the network a third packet; fast-path processing the 
third packet on the network interface device such that a data payload portion of the third 
packet is written into a destination memory without a network protocol stack performing 
substantial transport or substantial network layer protocol processing on the third packet." 
Kapoor does not teach or suggest these limitations because the client and server processes 
of Kapoor are running on the same host computer. 

Moreover, applicants respectfully disagree with the Office Action assertion that 
"Kapoor teaches that bypassing the transport layer "provides significant performance 
gains" for the transmission of packets through the network (e.g. Kapoor, col. 2, lines 44- 
49)." As noted above, the performance gains alleged by Kapoor are not over a network 
but rather when the "client and server processes are running on the same host machine." 

In addition, applicants respectfully disagree with the Office Action assertion that 
"It would have been obvious to one skilled in the art at the time the invention was made 
to combine Kapoor with Isfeld because of the advantages of allowing certain packets 
which do not need full protocol stack processing to avoid the unnecessary processing to 
avoid the unnecessary processing and be given a "fast-path" through the device." 
Kapoor, page 72, column 1, lines 27-29." As mentioned above, such advantages do not 
provide a "fast-path" through the device because Kapoor' s alleged advantage only works 
when "the client and server processes are running on the same host machine." 

Moreover, given that Isfeld is directed to "backbone communication links" and 
Kapoor is directed to when "the client and server processes are running on the same host 
machine," applicants respectfully assert that it is difficult to imagine that one of ordinary 
skill in the art would have combined these apparently exclusive devices to arrive at the 
combination proposed by the Office Action. 

For at least these reasons, applicants respectfully assert that claim 8 is nonobvious 
over the combination of Isfeld and Kapoor proposed by the Office Action. 
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Regarding claim 12, the Office Action states: 

As per claim 8, Isfeld and Kapoor teach the method of claim 8, 
wherein the network protocol stack is executed by a processor, the 
processor being a part of the network interface device (e.g. Kapoor, col. 2, 
lines 33-43). 

Column 2, lines 33-43 instead state: 

It is therefore a principal object of the invention for efficiently 
managing remote procedure calls (RPCs) between client and server 
processes running on the same host computer in a network. 

It is another object of the invention to enable a network RPC 
mechanism to distinguish whether client and server processes are running 
on the same host machine and, if so, to bypass the network and transport 
layers using an alternate protocol sequence that exploits local interprocess 
communication (IPC) facilities. 

Applicants respectfully note that this portion of Kapoor does not even mention a 
"processor" or a "network interface device," in contrast to claim 12. 

For at least these reasons, applicants respectfully assert that claim 12 is 
nonobvious over the combination of Isfeld and Kapoor proposed by the Office Action. 

Regarding claim 13, the Office Action states: 

As per claim 8, Isfeld and Kapoor teach the method of claim 8, 
wherein the network protocol stack is executed by a processor, the 
processor being a part of a host computer, the network interface device 
being coupled to the host computer (e.g. Kapoor, col. 2, lines 33-43). 

Column 2, lines 33-43 instead state: 

It is therefore a principal object of the invention for efficiently 
managing remote procedure calls (RPCs) between client and server 
processes running on the same host computer in a network. 

It is. another object of the invention to enable a network RPC 
mechanism to distinguish whether client and server processes are running 
on the same host machine and, if so, to bypass the network and transport 
layers using an alternate protocol sequence that exploits local interprocess 
communication (IPC) facilities. 

Applicants respectfully note that this portion of Kapoor does not even mention a 
"processor" or a "network interface device," in contrast to claim 13. 

For at least these reasons, applicants respectfully assert that claim 13 is 
nonobvious over the combination of Isfeld and Kapoor proposed by the Office Action. 
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3. The Office Action rejects claims 10 and 21-35 under 35 U.S.C. §103(a) as 
being unpatentable over Isfeld in view of Kapoor and in view of Lakshman. Regarding 
claim 10, the Office Action states: 

As per claim 10, Isfeld and Kapoor teach the method of claim 8, 
but fail to teach wherein the second TCP/IP packet is a TCP ACK. 

However, in a similar art, Lakshman teaches a network 
communications system that uses multiple transmit queues, one for control 
(ACK) packet pointers and one for data pointers (e.g. Lakshman, col. 4, 
lines 38-44, 53-59). 

It would have been obvious to one skilled in the art at the time the 
invention was made to further combine Lakshman with Isfeld because of 
the benefits of using an acknowledgement (ACK) response in a 
communications network. The use of ACK responses further assists a 
communications network in reducing network congestion and informs the 
transmitter when a packet has been dropped. This increases the speed, 
efficiency and reliability of a network, all of which are beneficial in any 
communications network system. 

Applicants respectfully disagree with the Office Action assertion that Isfeld and 
Kapoor teach the method of claim 8, as discussed above. 

Applicants also respectfully disagree with the Office Action statement that: "It 
would have been obvious to one skilled in the art at the time the invention was made to 
combine Lakshman with Isfeld because of the benefits of using an acknowledgement 
(ACK) response in a communications network." As mentioned above, Isfeld states, in 
column 1, line 67 - column 2, line 3: "Thus, it is desirable to limit the amount of control 
messages transmitted on the communication link among the distributed processing nodes 
in order to enhance data throughput," teaching away from the use of ACKs, which the 
Office Action asserts are control packets. 

Applicants also respectfully disagree with the Office Action assertion that: "The . 
use of ACK responses further assists a communications network in reducing network 
congestion," especially because this statement contradicts the teaching of Isfeld quoted 
immediately above. Because this assertion appears to come from the Examiner's 
personal knowledge rather than anything in the cited references, applicants respectfully 
request the Examiner to provide a supporting affidavit as required by 37 C.F.R. 
§1. 104(d)(2). 
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For at least these reasons, applicants respectfully assert that claim 10 is 
nonobvious over the combination of Isfeld and Kapoor and Lakshman proposed by the 
Office Action. 

Regarding claim 21, the Office Action states: 

As per claim 21, Isfeld teaches a method for outputting a control 
packet from a protocol processing offload network interface device 
(PPONID), the PPONID being coupled to a network (e.g. Isfeld, Abstract 
col. 1, lines 20-27), the method comprising: 

receiving a first packet onto the PPONID from the network (e.g. 
Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 

receiving a second packet onto the PPONID from the network (e.g. 
Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 

pushing a first pointer to first packet information onto a first 
transmit queue (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 

in response to said receiving of the second packet pushing a second 
pointer to second packet information onto a second transmit queue (e.g. 
Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 

popping the second transmit queue to retrieve the second pointer, 
and using the second pointer to retrieve the second packet information, 
and outputting the second packet information from the PPONID in the 
form of the control packet (e.g. Isfeld, col. 2, lines 54-67; col. 3, lines 1- 
15); and 

popping the first transmit queue to retrieve the first pointer, and 
using the first pointer to retrieve the first packet information, and 
outputting the first packet information from the PPONID in the form of a 
third packet, the ACK being output from the PPONID before the third 
packet (e.g. Isfeld, col. 2, lines 54-67; col. 3, lines 1-15). 

Isfeld fails to teach the method wherein the control packet is an 
acknowledgement (ACK) packet and the method comprising: slow-path 
processing the first packet such that a protocol processing stack performs 
substantial transport layer processing and substantial network layer 
processing on the first packet; fast-path processing the second packet on 
the PPONID such that the stack performs substantially no transport layer 
processing on the second packet and such that the stack performs 
substantially no network layer processing on the second packet. 

However, in a similar art, Kapoor teaches a network 
communication system that receives packets onto a network interface 
device and is able to perform both "fast-path" and "slow-path" processing 
on the packet, depending on certain characteristics determined at the time 
the packet is received; the "fast-path" processing avoids protocol 
processing in both the network and transport layers, accelerating the 
packet through the device (e.g. Kapoor, col. 2, lines 33-49; col. 6, lines 7- 
19; Fig. 2B) and the "slow-path" processing processes the packet through 
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all applicable layers of the protocol stack if it does not meet the defined 
requirements for "fast-path" processing (e.g. Kapoor, col. 5, lines 36-45). 

Also, in a similar art, Lakshman teaches a network 
communications system that uses multiple transmit queues, one for control 
(ACK) packets and one for data packet pointers, and the various uses of 
the ACK control packet (e.g. Lakshman, col. 4, lines 38-44, 53-59). 

It would have been obvious to one skilled in the art at the time the 
invention was made to combine Kapoor and Lakshman with Isfeld 
because of the benefits of using ACK responses and allowing packets to 
be processed only in the protocol layers which are necessary for 
transmission. The use of ACK responses further assists a communications 
network in reducing network congestion and informs the transmitter when 
a packet has been dropped. As Kapoor states, bypassing the unnecessary 
processing layers provides for significant performance gains (e.g. Kapoor, 
col. 2, lines 48-49). When the network device skips processing on each 
layer of the protocol stack, the packet passes through the device much 
faster and more efficiently. Only packets that need to be processed in 
each layer are pass through the "slow-path" which can greatly increase the 
speed and efficiency of network communication. All these features are 
beneficial in any communications network system. 

Applicants respectfully disagree with the Office Action assertion that Isfeld 

teaches "pushing a first pointer to first packet information onto a first transmit queue (e.g. 

Isfeld, col. 2, lines 59-63; col. 3, lines 16-29)." Instead, Isfeld states, in column 2, line 59 

- column 3, line 29: 

Thus, according to one aspect of the invention, it can be 
characterized as a method of transferring data on a communication 
medium from a source processor to a destination processor, wherein the 
data includes messages of a first transmit latency class and messages of a 
second transmit latency class. According to this aspect, messages of a first 
transmit latency class are queued at the source processor in a first transmit 
queue, and messages of the second transmit latency class are queued at the 
source processor in a second transmit queue. The first and second transmit 
queues operate to send messages on the communication link according to 
respective priority rules, such as a first-in first-out rules. According to this 
invention, a particular message selected from the first and second transmit 
queues in the source processor is sent on a communication link according 
to a queue priority rule to the destination processor without establishing 
connection with the destination processor for the particular message in 
advance. The queue priority rule provides, in one embodiment of the 
invention, for sending messages in the second transmit queue prior to 
sending any message in the first transmit queue, so long as a message 
resides in the second transmit queue. Other queue priority rules may be 
implemented, to ensure fairness or other parameters of a particular system. 
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Thus, a source processor is able to classify messages according to a 
transmit latency class, to ensure that certain classes of messages are 
transmitted quickly onto the communication link, while other classes of 
messages are handled in a best efforts type process. 

For example, the cited paragraph does not appear to mention a "first pointer to 
first packet information," in contrast to claim 21. 

Applicants also respectfully disagree with the Office Action assertion that Isfeld 
teaches "in response to said receiving of the second packet pushing a second pointer to 
second packet information onto a second transmit queue (e.g. Isfeld, col. 2, lines 59-63; 
col. 3, lines 16-29)." For example, the cited paragraph does not appear to mention a 
"second pointer to second packet information," in contrast to claim 21. 

Applicants further respectfully disagree with the Office Action assertion that 
Isfeld teaches "popping the second transmit queue to retrieve the second pointer, and 
using the second pointer to retrieve the second packet information, and outputting the 
second packet information from the PPONID in the form of the control packet (e.g. 
Isfeld, col. 2, lines 59-63; col. 3, lines 16-29)." None of these limitations appear to be 
found in Isfeld, in contrast to claim 21. 

Applicants further respectfully disagree with the Office Action assertion that 
Isfeld teaches "popping the first transmit queue to retrieve the first pointer, and using the 
first pointer to retrieve the first packet information, and outputting the first packet 
information from the PPONID in the form of a third packet, the ACK being output from 
the PPONID before the third packet (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29)." 
None of these limitations appear to be found in Isfeld, in contrast to claim 21. 

Applicants also respectfully disagree with the Office Action statement that 
"Kapoor teaches a network communication system that receives packets onto a network 
interface device and is able to perform both 'fast-path' and 'slow-path' processing on the 
packet, depending on certain characteristics determined at the time the packet is received; 
the 'fast-path' processing avoids protocol processing in both the network and transport 
layers, accelerating the packet through the device (e.g. Kapoor, col. 2, lines 33-49; col. 6, 
lines 7-19; Fig. 2B) and the 'slow-path' processing processes the packet through all 
applicable layers of the protocol stack if it does not meet the defined requirements for 
'fast-path' processing (e.g. Kapoor, col. 5, lines 36-45)." 
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Applicants note that instead of receiving packets onto a network interface device 
from a network and then avoiding protocol processing on the received packets, Kapoor is 
directed to "managing remote procedure calls (RPC's) between client and server 
processes running on the same host computer in a network." Kapoor, column 2, lines 
34-36, emphasis added. Similarly, Kapoor teaches: "It is another object of the invention 
to enable a network RPC mechanism to distinguish whether client and server processes 
are running on the same host machine and, if so, to bypass the network and transport 
layers using an alternate protocol sequence that exploits local interprocess 
communication (IPC) facilities." Kapoor, column 2, lines 37-43, emphasis added. 
Likewise, Kapoor teaches: "It is a more specific object of the invention to recognize 
when client and server DCE processes exist on the same host to thereby use a local IPC 
mechanism, instead of a network layer (IP) or transport layer (TP) path, to implement a 
remote procedure call." Kapoor, column 2, lines 44-48, emphasis added. 

In contrast to these teachings of Kapoor, claim 21 recites in part "receiving a 
second packet onto the PPONID from the network; fast-path processing the second 
packet on the PPONID such that the stack performs substantially no transport layer 
processing on the second packet and such that the stack performs substantially no 
network layer processing on the second packet." Kapoor does not teach or suggest these 
limitations because the client and server processes of Kapoor are running on the same 
host computer. 

Applicanfs^also respectfully disagree with the Office Action statement that: "It 
would have been obvious to one skilled in the art at the time the invention was made to 
combine Lakshman with Isfeld because of the benefits of using an acknowledgement 
(ACK) response in a communications network." As mentioned above, Isfeld states, in 
column 1, line 67 - column 2, line 3: "Thus, it is desirable to limit the amount of control 
messages transmitted on the communication link among the distributed processing nodes 
in order to enhance data throughput," teaching away from the use of ACKs, which the 
Office Action asserts are control packets. 

Applicants also respectfully disagree with the Office Action assertion that: "The 
use of ACK responses further assists a communications network in reducing network 
congestion," especially because this statement contradicts the teaching of Isfeld quoted 
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immediately above. Because this assertion appears to come from the Examiner's 
personal knowledge rather than anything in the cited references, applicants respectfully 
request the Examiner to provide a supporting affidavit as required by 37 CF.R. 
§1. 104(d)(2). 

For at least these reasons, applicants respectfully assert that claim 2 1 and all the 
claims that depend from claim 21 are nonobvious over the combination of Isfeld and 
Kapoor and Lakshman proposed by the Office Action. 

Regarding claim 22, the Office Action states: 

As per claim 22, Isfeld, Kapoor and Lakshman teach the method of 
claim 21, wherein PPONID is coupled to a host computer (e.g. Isfeld, col. 
6, lines 13-17), and wherein the second packet includes a data payload 
(e.g. Isfeld, col. 8, lines 50-544; col. 10, lines 44-47), the data payload 
being transferred from the PPONID and to the host, the ACK (e.g. 
Lakshman, col. 4, lines 38-44, 53-59) being output from the PPONID 
before any portion of the data payload is transferred to the host (e.g. Isfeld, 
col. 2, lines 59-63; col. 3, lines 16-29). 

Applicants respectfully assert that one of ordinary skill in the art would not have 
combined Isfeld, Kapoor and Lakshman absent the template provided by the present 
invention, as described above. 

Applicants also respectfully disagree with the Office Action assertion that "Isfeld 
Kapoor and Lakshman teach ... the data payload being transferred from the PPONID and 
to the host, the ACK (e.g. Lakshman, col. 4, lines 38-44, 53-59) being output from the 
PPONID before any portion of the data payload is transferred to the host (e.g. Isfeld, col. 
2, lines 59-63; col. 3, lines 16-29)." Applicants respectfully assert that there is simply no 
teaching in any of the cited references, alone or in the proposed combination, of 
outputting an ACK prior to transferring the data payload to the host. 

For at least these reasons, applicants respectfully assert that claim 22 and all the 
claims that depend from claim 22 are nonobvious over the combination of Isfeld and 
Kapoor and Lakshman proposed by the Office Action. 

Regarding claim 23, the Office Action states: 

As per claim 23, Isfeld teaches a method for outputting a control 
packet from a network interface device, the network interface device being 
coupled to a network (e.g. Isfeld, Abstract col. 1, lines 20-27), the method 
comprising: 
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receiving a first TCP/IP packet onto the network interface device 
from the network (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 

receiving a second TCP/IP packet onto the network interface 
device from the network (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16- 
29); 

pushing a first pointer to third packet information onto a first 
transmit queue (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 

in response to said receiving of the second TCP/IP packet pushing 
a second pointer to fourth packet information onto a second transmit 
queue (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 

popping the second transmit queue to retrieve the second pointer, 
and using the second pointer to retrieve the fourth packet information, and 
outputting the fourth packet information from the network interface device 
in the form of the TCP ACK (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 
16-29); and 

popping the first transmit queue to retrieve the first pointer, and 
using the first pointer to retrieve the third packet information, and 
outputting the third packet information from the network interface device 
in the form of a third TCP/IP packet, the TCP ACK being output from the 
network interface device before the third TCP/IP packet (e.g. Isfeld, col. 2, 
lines 59-63; col. 3, lines 16-29). 

Isfeld fails to teach the control packet being a TCP/IP ACK from a 
network device and the method comprising: slow-path processing the first 
TCP/IP packet such that a protocol processing stack performs substantial 
TCP layer processing and substantial IP layer processing on the first 
TCP/IP packet; fast-path processing the second TCP/IP packet on the 
network interface device such that the stack performs substantially no TCP 
layer processing on the second TCP/IP packet and such that the stack 
performs substantially no IP layer .processing on the second TCP/IP 
packet. 

However, in a similar art, Kapoor teaches a network 
communication system that receives packets onto a network interface 
device and is able to perform both "fast-path" and "slow-path" processing 
on the packet, depending on certain characteristics determined at the time 
the packet is received; the "fast-path" processing avoids protocol 
processing in both the network and transport layers, accelerating the 
packet through the device (e.g. Kapoor, col. 2, lines 33-49; col. 6, lines 7- 
19; Fig. 2B) and the "slow-path" processing processes the packet through 
all applicable layers of the protocol stack if it does not meet the defined 
requirements for "fast-path" processing (e.g. Kapoor, col. 5, lines 36-45). 

Also, in a similar art, Lakshman teaches a network 
communications system that uses multiple transmit queues, one for control 
(ACK) packets and one for data packet pointers, and the various uses of 
the ACK control packet (e.g. Lakshman, col. 4, lines 38-44, 53-59). 
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It would have been obvious to one skilled in the art at the time the 
invention was made to combine Kapoor and Lakshman with Isfeld for 
reasons similar as stated above in regards to claim 21. 

Applicants respectfully disagree with the Office Action assertion that Isfeld 
teaches "receiving a first TCP/IP packet onto the network interface device from the 
network (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29)." As noted above, Isfeld 
teaches away from using a connection-oriented protocol such as TCP. 

Applicants also respectfully disagree with the Office Action assertion that Isfeld 
teaches "receiving a second TCP/IP packet onto the network interface device from the 
network (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29)." As noted above, Isfeld 
teaches away from using a connection-oriented protocol such as TCP. 

Applicants further respectfully disagree with the Office Action assertion that 
Isfeld teaches "pushing a first pointer to third packet information onto a first transmit 
queue (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29)." The cited paragraph of Isfeld, 
which is reprinted above, does not contain such a teaching. 

Applicants further respectfully disagree with the Office Action assertion that 
Isfeld teaches "in response to said receiving of the second TCP/IP packet pushing a 
second pointer to fourth packet information onto a second transmit queue (e.g. Isfeld, col. 
2, lines 59-63; col. 3, lines 16-29)." The cited paragraph of Isfeld, which is reprinted 
above, does not contain such a teaching, and Isfeld teaches away from using a 
connection-oriented protocol such as TCP. 

Applicants further respectfully disagree with the Office Action assertion that 
Isfeld teaches "popping the first transmit queue to retrieve the first pointer, and using the 
first pointer to retrieve the third packet information, and outputting the third packet 
information from the network interface device in the form of a third TCP/IP packet, the 
TCP ACK being output from the network interface device before the third TCP/IP packet 
(e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29)." The cited paragraph of Isfeld, which 
is reprinted above, does not contain such a teaching, and Isfeld teaches away from using a 
connection-oriented protocol such as TCP. 

Applicants also respectfully disagree with the Office Action statement that 
"Kapoor teaches a network communication system that receives packets onto a network 
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interface device and is able to perform both 'fast-path' and 'slow-path' processing on the 
packet, depending on certain characteristics determined at the time the packet is received; 
the 'fast-path' processing avoids protocol processing in both the network and transport 
layers, accelerating the packet through the device (e.g. Kapoor, col. 2, lines 33-49; col. 6, 
lines 7-19; Fig. 2B) and the 'slow-path' processing processes the packet through all 
applicable layers of the protocol stack if it does not meet the defined requirements for 
'fast-path' processing (e.g. Kapoor, col. 5, lines 36-45)." 

Applicants note that instead of receiving packets onto a network interface device 
from a network and then avoiding protocol processing on the received packets, Kapoor is 
directed to "managing remote procedure calls (RPCs) between client and server 
processes running on the same host computer in a network." Kapoor, column 2, lines 
34-36, emphasis added. Similarly, Kapoor teaches: "It is another object of the invention 
to enable a network RPC mechanism to distinguish whether client and server processes 
are running on the same host machine and, if so, to bypass the network and transport 
layers using an alternate protocol sequence that exploits local interprocess 
communication (IPC) facilities." Kapoor, column 2, lines 37-43, emphasis added. 
Likewise, Kapoor teaches: "It is a more specific object of the invention to recognize 
when client and server DCE processes exist on the same host to thereby use a local IPC 
mechanism, instead of a network layer (IP) or transport layer (TP) path, to implement a 
remote procedure call." Kapoor, column 2, lines 44-48, emphasis added. 

In contrast to these teachings of Kapoor, claim 23 recites in part "receiving a first 
TCP/IP packet onto the network interface device from the network; slow-path processing 
the first TCP/IP packet such that a protocol processing stack performs substantial TCP 
layer processing and substantial IP layer processing on the first TCP/IP packet; receiving 
a second TCP/IP packet onto the network interface device from the network; fast-path 
processing the second TCP/IP packet on the network interface device such that the stack 
performs substantially no TCP layer processing on the second TCP/IP packet and such 
that the stack performs substantially no IP layer processing on the second TCP/IP 
packet." Kapoor does not teach or suggest these limitations because the client and server 
processes of Kapoor are running on the same host computer. 
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Applicants also respectfully disagree with the Office Action statement that: "It 
would have been obvious to one skilled in the art at the time the invention was made to 
combine Kapoor and Lakshman with Isfeld for reasons similar as stated above in regards 
to claim 21. As noted above, there are many reasons why one of such skill would not 
have made the combination proposed by the Office Action. 

For at least these reasons, applicants respectfully assert that claim 23 and all the 
claims that depend from claim 23 are nonobvious over the combination of Isfeld and 
Kapoor and Lakshman proposed by the Office Action. 

4. The Office Action rejects claims 29 and 30 under 35 U.S.C. § 103(a) as 
being unpatentable over Kapoor in view of Isfeld. Regarding claim 29, the Office Action 
states: 

As per claim 29, Kapoor teaches a TCP/IP offload device, the 
TCP/IP offload device being coupled to a device that executes a protocol 
stack, wherein the TCP/IP offload device accelerates TCP and IP protocol 
processing of an incoming TCP/IP packet such that the stack performs 
substantially no TCP protocol processing on the TCP/IP packet and such 
that the stack performs substantially no IP protocol processing on the 
TCP/IP packet, and wherein a data portion of the TCP/IP packet is 
transferred from the TCP/IP offload device to the device that executes the 
protocol stack (e.g. Kapoor, col. 2\ lines 33-49; col. 6, lines 7-19; Fig. 2B). 

Kapoor fails to teach the TCP/IP offload device comprising: a first 
transmit queue containing pointers associated with a first set of packets; 
and a second transmit queue containing pointers associated with a second 
set of packets, wherein the second set of packets has transmission priority 
over the first set of packets. 

However, in a similar art, Isfeld teaches a system that uses two 
separate transmit queues to store pointers to memory locations containing 
data packet information and control packet information, and where the 
second transmit queue has transmission priority over the first transmit 
queue (e.g. Isfeld, col. 2, lines 54-67; col. 3, lines 1-15). 

It would have been obvious to one skilled in the art at the time the 
invention was made to combine Isfeld with Kapoor because of the 
advantages of using separate transmit queues for storing pointers to 
different types of information. This allows the data information and 
control information to remain separated and provides for a variation in 
processing to be done to one queue and not the other. Keeping data and 
control information separate reduces the time spent for the processor to 
determine which type of information it is dealing with every time it needs 
to process a packet. This allows the processor to quickly and efficiently 
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conduct the necessary processing and transmit the packet appropriately. 
The increase in speed and efficiency is a benefit in any communications 
network system. 

Applicants respectfully disagree with the Office Action assertion that Kapoor 
teaches "a TCP/IP offload device, the TCP/IP offload device being coupled to a device 
that executes a protocol stack, wherein the TCP/IP offload device accelerates TCP and IP 
protocol processing of an incoming TCP/IP packet such that the stack performs 
substantially no TCP protocol processing on the TCP/IP packet... (e.g. Kapoor, col 2, 
lines 33-49; col. 6, lines 7-19; Fig. 2B)." 

Instead of "processing an incoming packet" and instead of having a "TCP/IP 
offload device being coupled to a device that executes a protocol stack" as recited in 
claim 29, Kapoor is directed to "managing remote procedure calls (RPC's) between client 
and server processes running on the same host computer in a network." Kapoor, 
column 2, lines 34-36, emphasis added. Similarly, Kapoor teaches: "It is another object 
of the invention to enable a network RPC mechanism to distinguish whether client and 
server processes are running on the same host machine and, if so, to bypass the 
network and transport layers using an alternate protocol sequence that exploits local 
interprocess communication (IPC) facilities." Kapoor, column 2, lines 37-43, emphasis 
added. Likewise, Kapoor teaches: "It is a more specific object of the invention to 
recognize when client and server DCE processes exist on the same host to thereby use a 
local IPC mechanism, instead of a network layer (IP) or transport layer (TP) path, to 
implement a remote procedure call." Kapoor, column 2, lines 44-48, emphasis added. 

In contrast to these teachings of Kapoor, claim 29 recites in part "wherein the 
TCP/IP offload device accelerates TCP and IP protocol processing of an incoming 
TCP/IP packet such that the stack performs substantially no TCP protocol processing on 
the TCP/IP packet and such that the stack performs substantially no IP protocol 
processing on the TCP/IP packet." Kapoor does not teach or suggest these limitations 
because the client and server processes of Kapoor are running on the same host computer. 

For similar reasons, Kapoor does not teach "wherein a data portion of the TCP/IP 
packet is transferred from the TCP/IP offload device to the device that executes the 
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protocol stack (e.g. Kapoor, col. 2, lines 33-49; col. 6, lines 7-19; Fig. 2B)," in contrast to 
claim 29 and the Office Action assertions. 

Applicants respectfully disagree with the Office Action assertion that "It would 
have been obvious to one skilled in the art at the time the invention was made to combine 
Isfeld with Kapoor because of the advantages of using separate transmit queues for 
storing pointers to different types of information." Because Isfeld is directed to 
"backbone communication links" and Kapoor is directed to when "the client and server 
processes are running on the same host machine," applicants respectfully assert that it is 
difficult to imagine that one of ordinary skill in the art would have combined these 
apparently exclusive devices to arrive at the combination proposed by the Office Action. 

Applicants also respectfully disagree with the Office Action assertion that: 
"Keeping data and control information separate reduces the time spent for the processor 
to determine which type of information it is dealing with every time it needs to process a 
packet." Because this assertion appears to come from the Examiner's personal 
knowledge rather than anything in the cited references, applicants respectfully request the 
Examiner to provide a supporting affidavit as required by 37 C.F.R. § 1.104(d)(2). 

For at least these reasons, applicants respectfully assert that claim 29 and all the 
claims that depend from claim 29 are nonobvious over the combination of Isfeld and 
Kapoor proposed by the Office Action. 

Regarding claim 30, the Office Action states: 

As per claim 30, Kapoor and Isfeld teach the TCP/IP offload 
device of Claim 29, wherein the TCP/IP packet is received onto the 
TCP/IP offload device from a network, and wherein the TCP/IP offload 
device includes means for outputting the first set of packets and the second 
set of packets from the TCP/IP offload device and to the network (e.g. 
Kapoor, col. 2, lines 33-49; col. 6, lines 7-19). 

Applicants respectfully assert that, in contrast to the recitation in claim 30 that 
"the TCP/IP packet is received onto the TCP/IP offload device from a network," the 
client and server processes of Kapoor are running on the same host computer. For at 
least this reason, applicants respectfully assert that claim 30 is nonobvious over the 
combination of Isfeld and Kapoor proposed by the Office Action. 
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III. Allowable Subject Matter 

Applicants appreciate the acknowledgement that claims 19, 20, 26, 27 and 28 
contain patentable subject matter. 

IV. Conclusion 

Applicants have responded to each of the items in the Office Action, and believe 
that all of the pending claims are in condition for allowance. As such, applicants 
respectfully solicit a Notice of Allowance. 



Respectfully submitted, 
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